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I. 


INTRODUCTION 


At  present,  most  shipboard  information  handling 
operations  are  performed  manually  and  are  cumbersome  and 
often  unreliable.  Additionally,  the  manual  operations  are 
labor  consuming  to  the  extent  that  they  pose  a  threat  to  the 
Navy's  personnel  and  operational  readiness.  If  personnel 
and  operational  readiness  are  to  be  maintained  in  a  period 
of  declining  available  resources,  a  more  efficient  and 
effective  means  of  information  handling  must  be  employed. 

The  objective  of  this  research  was  to  outline  an 
approach  to  utilize  existing  automated  data  processing 
technology  in  a  shipboard  environment  in  an  effort  to  reduce 
the  percentage  of  time  shipboard  personnel  devote  to 
repetitive  administrative  functions.  Although  specific 
hardware  selection  was  not  an  intended  objective,  issues 
ccrcerning  hardware  and  software  selection  were  investigated 
as  they  related  to  a  shipboard  environment.  This  effort  was 
pursued  because  selection  of  a  particular  hardware  suit  can 
impcse  system  limitations  that  can  dictate  success  or 
failure  for  the  system. 

Investigation  of  shipboard  administration  functions 
revealed  several  functions  which  are  likely  candidates  for 
automation.  Differences  in  ships'  size  and  mission  are 
analogous  to  differences  in  commercial  companies.  Each  has 
varied  functions  that  are  critical  in  one  organization  and 
of  little  ccnsegnence  in  another.  This  paper  focuses  on  the 
problems  cf  automating  management  functions  aboard  ships 
with  manning  levels  below  500  personnel.  As  repeatedly 
emphasised  in  Ref.  1,  a  function  or  system  that  is  not  well 
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defined  cr  is  not  successfully  operating  in  a  manual  mode, 
will  fail  when  automated.  Keeping  this  fact  in  mind  while 
concentrating  on  functions  that  were  extremely  time 
consuming,  led  to  selection  of  the  following  functions  for 
automation  consideration: 

1.  Shipboard  Training  and  Hecord-Keeping 

2.  Maintenance  of  Personnel  Records 

2.  Paper  Inputs  to  the  Manpower  and  Personnel 

System  (MAPMIS) 

Automating  these  functions  exploits  the  commonality  of 
the  data  base  elements  required  to  support  them.  This  paper 
provides  an  analysis  of  the  data  base  requirements  and  the 
design  considerations  to  successfully  generate  the 
applications  programs  that  collectively  compose  the  ship’s 
automated  management  system. 


9 


II.  BACKGROUND 


Several  efforts  have  been  made  to  develop  computer-based 
shipboard  management  systems.  These  efforts  have  been 
fragmentary  in  nature.  Results  have  been  isolated 

computer-based  packages  which  do  not  exploit  the  extensive 
ccmmcnality  cf  data  base  elements  that  support  several 
levels  cf  nanagement.  Additionally,  the  interfacing  with 
higher  levels  cf  command  has  been  ignored  in  their  design. 
As  an  example,  a  shipboard  personnel  record-keeping  package 
reguires  almost  identical  data  base  elements  as  that  of  the 
data  base  utilized  by  the  Bureau  of  Naval  Personnel  (EUPERS) . 
A  properly  designed  shipboard  data  base  shculd  be  capable  of 
automated  preparation  of  inputs  to  the  BUPERS  data  base. 

Related  efforts  to  that  of  the  shipboard  computer  based 
management  system  that  have  beem  pursued  within  the  Navy  are 
as  fellows: 

1.  Data  Entry  Aboard  Ship  (DEAS)  Project 
(CGMNAVSUPS3SC0M) 

2.  Development  and  Maintenance  of  Continuous  Ship 
Maintenance  Pro j ect  (CSMP)  by  Minicomputers  (CNM) 

3.  Data  Processing  in  MLSF  Ships.  Computer-based  system 
supporting  supply,  3-M,  and  administrative  functions 

in  MLSE  ships  with  Burroughs  L3200  system  installed 
( COMN  A  1 S  UP  SI SCO M ) 

4.  Application  cf  Shipboard  Computers  to  Instruction 
and  Training  Administration.  (NPRDC) 
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5.  Shipboard  L-Tran  (Lesson  Translator).  Current 
shipboard  CAI  for  NTDS  operators. 

Additionally,  the  following  efforts  to  automate 
shipboard  functions  are  of  particular  interest  to  future 
applicat icns : 


A.  APPLICATIONS  ABOARD  USS  DAHLGEEN 


References  2-14  describe  effcrts  sponsored  by  the  Navy 
Personnel  Research  and  Development  Center  (NPRDC)  to  utilize 
a  minicomputer  tc  automate  shipboard  functions.  The 
minicomputer  utilized  was  a  commercial  version  that  did  not 
meet  Military  Specif icaticns (MILSPECS)  for  shipboard 
employment.  The  system  description  and  applications  were  as 
fellows: 


1 •  Bard  ware  and  Software  Description 


The  system  hardware  and  software  avaialable  for 
utilization  aboard  USS  Dahlgren  consisted  of  the  following: 

CENTRA!  EECCESSI NG  UNIT  (NOVA  1200) 

16  bit  wcrd-32K  words  memory 
memory  cycle  time-1.2  micro  seconds 
physical  size-E  10-5*  * ,  W  19*',  D  23  * • 
power  interrupt  protected 
real  time  clock 

TELETYPE  (ASH-33) 

10  characters  per  second 
paper  tape  reader  and  punch 
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CABD  R  E ABEB 

225  cards  per  minute 
table  tcp  mounted 

DISK  OBIT 
fixed  head 

drive  unit  (512K  words  per  unit) 
interchangeable  disk  packs 

LINE  PRINTER 

356  lines  per  minute 
132  columns  per  line 
table  tcp  mounted 
OCB-A  font 

MAGNETIC  TAPE  CASSETTE  UNITS  (6) 

5  tape  drives 

CBT  REMOTE  TERMINALS 
table  tcp  mounted 
20  lines-60  characters  per  line 
physical  size-H  15”,  W  17”,  C  27” 

EORTBAN  COMPILER 

ALGOL  CCMEIIER 

EXTENDEE  EASIC  INTEBPRETER 

EXTENDEE  ASSEMELEB 

EELOCAT A  EIE  LOADER 

EELCCA TABLE  MATH  PACKAGE 

BEAL  TIME  EISC  OPERATING  SYSTEM  (RDOS) 

BEAL  TIKE  OPERATING  SYSTEM  (RTOS) 

EISC  OPERATING  SYSTEM  (DOS) 


2  •  Applications 


Two  cf  the  more  significant  applications  applied  to 
the  NOVA  1200  were  the  development  of  a  computer  assisted 
instruction  package  to  teach  shipboard  Damage  Control  and 
the  automation  of  Supply  Department  functions. 


Reference  13  describes  in  detail  the  computer 
assisted  instruction  effort.  The  programs  were  designed  to 
rur  under  the  REOS  operating  system  and  were  written  in 
Extended  EASIC,  version  3.6.  The  programs  were  designed  as  a 
series  cf  overlays  to  be  operated  in  a  multi-user 
environment  and  in  the  swapping  mode  of  BASIC.  The  system 
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contained  an  executive  program  and  19  subprograms  capable  of 
accessing  twc  data  files:  a  student  data  base,  and  an 
examination  statistics  file. 

The  course  of  instruction  was  designed  to  satisfy 
current  Personnel  Qualification  Standards  (PQS)  in  Eamage 
Control.  Instruction  was  given  off-line  using  textual 
material.  Examinations  were  taken  on-line  via  CRT.  Students 
taking  an  examination  were  furnished  on-line  and  harc-copy 
test  results,  diagnostics,  and  corrective  actions  for 
improvement . 

The  effort  to  automate  the  supply  functions  was 
primarily  the  result  of  work  done  by  University  of 
Pennsylvania  Wharton  graduate  students.  A  system  titled  USS 
Dahlgren  Autcmated  Logistics  Control  and  Report  Generating 
System (LOGCCN)  was  developed  to  provide  detailed  supply 
infcrmaticn  in  a  matter  of  seconds.  LOGCCN  consisted  of 
eight  unique  programs.  The  software  documentation  fcr  all 
the  programs  is  included  in  Ref.  15.  LOGCCN  utilized  four 
data  files:  two  were  random-access  disk  files  and  the  other 
twc  were  sequentially  accessed  tape  files.  10GC0N  had  the 
capability  tc  prepare  supply  requisitions,  determine  if 
stock  was  available  to  satisfy  a  requisition,  and  tc  order 
up  the  high  limit  of  an  item  when  available  stock  was  at  or 
below  its  specified  low  level. 

B.  A  TRAINING  MANAGEMENT  SYSTEM 

In  early  1975  the  findings  on  the  Pacific  Fleet 
Prcpulsicn  Examining  Board  were  that  procedures  being 
employed  within  the  Engineering  Department  of  USS  Kitty 
Hawk(CV-63)  for  the  management  of  training  were  ineffective. 
The  principal  problem  being  that  the  cumbersome  manual 
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system  f cr  recording  Personnel  Qualification  Standards  (FQS) 
training  data  proved  an  inadequate  mechanism  for  the 
Training  Cfficer  tc  effectively  supervise  and  coordinate  the 
training.  The  operational  unit  commander (Ccmmande r  Carrier 
Division  Cne)  initiated  action  to  investigate  automation  of 
the  traininc  function  to  make  it  more  responsive  to  the 
several  levels  of  management  within  the  ship. 

1 •  System  Description 

1 w c  computer  systems  were  available  for  use  in 
designing  the  computer  based  training  management  system;  the 
iUK  1500  system  and  a  Micro  Data  1600  system.  The  two 
systems  were  compared  in  terms  of  their  data  processing 
characteristics  and  user  convenience  by  personnel  from  the 
Naval  Electronics  Laboratory  Center  (NEIC)  and  the  Naval 
Personnel  Research  and  Development  Center  (NFRDC) .  The  Micro 
Data  system  with  the  addition  of  a  CRT  terminal  and  printer 
was  selected  for  use.  The  general  operating  characteristics 
offered  by  the  system  were: 

1.  Inexpensive  terminal  installed  within  the 

Engineering  Department 

2.  Total  time  sharing;  random  access 

3.  Individual  update  capability 

4.  Records  available  on-line  at  all  times 

5.  Flexible  sorting  capability  permitting  varied 

reporting  formats. 
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2. 


Cat a  Base  Design  Criteria 

In  designing  the  elements  to  be  included  in  the  data 
base,  the  objective  was  to  include  sufficient  elements  to  be 
able  tc  format  meaningful  training  reports  tc  various  levels 
of  command  while  utilizing  PQS  as  the  basic  vehicle  for 
training  and  assignment  of  individuals.  This  design  criteria 
was  incorporated  to  make  the  basic  system  relocatable  for 
use  by  any  cperaticnal  units  employing  PQS. 

The  Department  Head,  Executive  Officer,  and 
Commanding  Officer  required  summary  information  to  indicate 
the  status  of  training  at  a  given  time.  Typical  data 
elements  usee  in  generating  this  level  of  report  were: 

1.  BQEl-tte  number  of  stations  manned  during  Condition  1 

2.  ASGHl-rumber  of  personnel  assigned  to  a  station 
during  condition  1 

3.  ANQI-number  assigned  this  watch  station  not  PQS 
g  ualif ied 

Bepcrts  generated  for  use  by  the  Division  Officer 
reguired  specific  information  on  individuals  tc  assess 
previous  training,  and  to  determine  work  assignments. 
Typical  data  elements  utilized  to  generate  this  report  were: 

1.  PQS-the  PQS  number  assigned  to  the  watch  station 

2.  TRNG-number  of  personnel  in  training  for  the  watch 
station 
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3.  CEIT-FFE-numh er  of  watch  station  personnel  with  FED 

less  than  60  days 

Space  supervisors  utilized  seme  of  the  information 
available  in  the  Division  Officers  report,  but  required 
specific  information  on  individuals  in  their  work  centers. 
One  of  the  primary  considerations  in  designing  the  data 
elements  was  to  facilitate  alphabetical  sorting  cf 
individuals  when  information  is  desired  on  a  single 
individual.  Sample  data  elements  utilized  in  preparing  the 
reports  for  werk  center  supervisors  are: 

1.  NAME-last  name  of  individual 

2.  COSEI-watch  station  assigned  for  Condition  1 

3.  L-EATE-FED  or  discharge  date 


C.  EESDIiS 


Althcugh  much  time  and  effort  was  devoted  to 
aforementioned  systems,  very  little  practical 
resulted  from  either.  The  reason  for  this  lack  of 
can  be  attributed  to  personnel  involvement  and  the 
utilized . 


the  two 
benefit 
results 
hardware 


In  beth  systems,  enthusiastic  personnel  worked  on  their 
implementation ,  but  failed  to  get  non-computer  oriented 
personnel  involved  in  the  development.  As  personnel  were 
rotated,  lack  of  system  understanding  resulted  in  users 
losing  confidence  in  the  systems  and  returning  to  manual 
methods  cf  performing  the  functions. 


The  hardware  utilized  in  both  systems  was  off-the-shelf 
computing  equipment.  The  systems  had  to  be  designed  to  fit 
the  capabilities  of  the  existing  hardware.  Varying  underway 
conditions  caused  system  readiness  to  be  unpredictable. 


16 


Specifically,  DAHLGBEN  experienced  reliability  problems  with 
the  fixed  head  disk  drive  units  in  heavy  seas.  An  automated 
data  system  that  displays  marginal  reliability  is  little 
improvement  ever  manual  operations. 
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III.  SYSTEM  DESIGN  CONSIDERATIONS 


A  question  often  asked  when  discussing  automation  of 
ncn-tactical  shipboard  functions  is,  "Can  existing  shipboard 
computer  systems  be  utilized?"  On  many  combatant  ships 
existing  computer  systems (e. g.  NTDS)  are  an  integral  part  of 
weapons  systems  or  tactical-support  systems.  Reference  16 
was  a  survey  made  to  determine  the  suitability  and 
availability  of  onboard  computers  for  training  and  ether 
non-tactical  utilizations.  The  results  of  the  survey  were 
that  computers  installed  for  tactical  purposes  were 
hard-wired  and  not  configured  for  ether  purposes  and  these 
computers  were  generally  not  available  for  other  uses  when 
the  ship  was  underway. 

The  acquisition  of  any  computing  system  involves 
detailed  evaluation  of  tangible  and  ether  not  easily 
measured  factors.  The  comparison  of  computing  systems  in 
terms  of  hardware  performance  factors  such  as  speed  and 
storage  capability  are  straightforward  measurements.  Cn  the 
ether  hand,  the  evaluation  of  the  reputation  of  a  particular 
vendor  and  the  problems  of  interfacing  his  equipment  with 
that  of  another  vender  are  abstract  considerations  that  must 
also  be  taken  into  account  when  selecting  a  system. 
Reference  1  provides  a  comprehensive  checklist  for 
utilization  in  system  comparisons.  Issues  of  particular 
interest  to  the  shipboard  environment  are  the  following: 

1.  Reliability 

2.  Physical  Planning  Consider ations 

3.  Mini  vs  Micro  Computer 

4.  Software  Considerations 
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A.  RELIABILITY 


In  the  selection  of  most  computing  systems  ,  cost  often 
has  been  the  dominant  criteria  influencing  the  selection 
decision.  Ic  the  case  of  the  shipboard  system  other  factors 
must  be  given  greater  weight  in  evaluating  systems  of 
comparable  operating  performance.  Reliability  of  the  system 
should  be  a  major  consideration  in  selection  of  any  hardware 
suit.  Two  of  the  most  commonly  used  criteria  to  evaluate 
reliability  are  Mean  Time  Between  Failure  (MTBF)  and  Mean 
Time  to  Repair  (MTTR) . 

References  17  and  18  enumerate  the  Standard  Military 
Specif icaticES  that  have  teen  developed  for  the  protection 
of  shipboard  electrical  equipment.  Although  utilization  of 
MIISFECS  is  required  and  results  in  improved  reliability, 
the  purchaser  must  be  aware  of  the  price  he  must  pay  to 
ensure  compliance  with  MILSPECS. 

An  example  of  the  cost  of  complying  to  MILSPECS  can  be 
seen  by  comparing  a  Data  General  830  with  a  Rolm  1602. 
These  two  miri-ccm puter  systems  use  the  same  circuit  design 
and  software.  The  Data  General  830  is  designed  to  meat 
commercial  needs  while  the  Rolm  1602  is  a  militarized 
version.  A  comparison  of  the  two  systems,  each  configured 
with  the  basic  computer,  32K  core  memory,  a  control  panel,  a 
power  monitor,  and  an  automatic  restart  capability;  revealed 
the  Rolm  1602  purchase  cost  ($48,650)  to  be  mere  than  double 
that  of  the  Data  General  830  ($ 18,  05 0)  .  Cn  the  reliability 
side,  the  Rolm  1602  had  a  MTBF  of  13,200  hours  as  compared 
to  the  Data  General  830  with  a  MTBF  of  4510  hours.  Assuming 
repair  parts  and  technical  expertise  were  available  when  a 
failure  occurred,  there  was  no  significant  difference  in  the 
MTTR  of  the  two  systems. 
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The  above  comparisons  while  rather  crude  in  nature 
highlight  a  simple  fact  the  purchaser  of  a  shipboard  system 
must  recognize.  It  will  cost  more  in  dollars  to  perform  an 
automated  function  afloat  than  to  perform  the  same  function 
at  a  shore-based  activity.  This  fact  must  be  recognized  and 
documented  when  performing  the  economic  analysis  required  to 
justify  purchase  of  the  system. 

E.  PHYSICAL  PLANNING  CONSIDEEATIONS 


Once  the  performance  design  characteristics  of  the 
system  have  been  established,  system  location  plans  must  be 
carefully  considered  before  a  particular  system  is  selected. 
When  commercial  systems  are  procured,  system  performance  is 
given  top  consideration.  Space  requirements  are  secondary  in 
nature,  usually  resulting  in  space  being  obtained  (purchase 
or  rental)  tc  meet  the  requirements  of  the  system  selected. 
Space  aboard  most  ships  in  commission  in  the  United  States 
Navy  is  a  critical  factor.  The  addition  of  any  electrical 
equipment  cften  requires  removal  of  some  existing  equipment 
or  the  reduction  of  space  allocated  to  personnel 
habitability.  This  requires  that  space  requirements  be  a 
major  factor  in  system  selection.  At  a  minimum  the 
following  factors  should  be  closely  examined  in  determining 
the  suitability  of  a  space  for  installation  of  a  computing 
system : 

1.  Overall  Sguare  Footage 

2.  Deck  leading  Restrictions 

3.  Air  Conditioning 

4.  Humidity  Control 

5.  Cable  Length  Requirements 

6.  Laycut  of  Cable  Trunks 

7.  Voltage  Reguirements 

6.  Ability  to  Keep  Space  Dust  Free 
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c. 


MINI  *S  MICRO  COMPUTER 


The  functions  proposed  for  automation  within  this  paper 
reguire  prompt  responses  from  the  computing  system  to 
warrant  automation.  They  do  not,  however,  reguire  the  high 
instruction  execution  speeds  available  in  many  present  day 
large-scale  machines.  This  fact  coupled  with  the  space 
restrictions  previously  mentioned,  reduce  the  choice  to  that 
of  a  mini-computer  system  or  a  micro-computer  system. 

Price  and  space  reguiremenrs  make  the  use  of  a 
micro-computer  an  attractive  alternative.  Technclcgical 
development  cf  the  micro-computer  has  been  limited  only  by 
the  all  important  corresponding  software  development.  In 
fact,  many  authors  have  pointed  out  that  the  introduction  of 
the  micro-computer  has  put  software  development  for  these 
devices  tack  at  the  point  where  software  was  for 
macro-computers  in  the  early  1950's.  Until  software 
development  for  micro-computers  catches  up  tc  the 
technological  hardware  developments,  a  mini-computer  is  the 
cnly  logical  choice  for  use  in  automating  shipboard 
administrative  functions. 


D.  SOFTiABE  CCNSIIERATIONS 


There  exist  many  issues  in  implementing  a  data 
processing  system  on  a  mini-computer.  To  properly  exploit 
the  strengths  and  weaknesses  of  the  mini-computer  several 
software  issues  as  they  apply  to  various  applications  must 
be  resolved.  Reference  15  addresses  many  of  the  issues 
including  the  following: 
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1.  Program  Complexity 

2.  Storage  Utilization 

3.  Operating  System  Complexity 

4. -  Extent  of  Documentation 

5.  Assembly  vs  High  Level  Language 

1  •  |rcc[ram  Cc  mplexity 

+ 

In  many  applications  the  knowledge  of  what  gees  on 
within  a  program  is  of  little  consequence  to  the  user.  When 
a  programmer  writes  a  progam  for  his  own  use  he  may  violate 
as  many  of  tie  principles  of  good  programming  as  he  chooses. 
In  general  though  there  exists  a  trade-off  between 
programmer  care  and  user  skill.  The  term  "user"  as  applied 
to  the  shipboard  environment  ranges  from  the  Data  Processing 
Technician  (DP) ,  who  will  be  responsible  for  maintaining 
certain  programs,  to  the  Seaman  who  will  be  expected  to 
operate  an  cr-line  terminal  as  part  of  the  training  system. 

The  varied  intelligence  and  backgrounds  of  the 
shipboard  users  is  such  that  the  programs  written  must 
display  a  high  degree  of  "intelligence" .  The  cues  for 
interaction  must  be  precise  and  simple.  The  programs  must 
give  concise  error  messages  notifying  the  user  when  he  has 
supplied  unacceptable  or  impossible  data.  Programs  that  may 
reguire  future  shipboard  modification  must  invoke  simple, 
well  documented  logic  to  account  for  the  inexperienced  DPs. 
The  trade-o-ff  for  this  action  is  larger,  less  efficient 
programs.  In  the  commercial  environment  mere  emphasis  is 
placed  on  the  efficient  use  of  the  limited  memory  normally 

associated  with  a  mini-computer  system.  In  the  shipboard 

environment  the  success  of  the  system  will  depend  upon  the 

degree  of  usage  by  a  cross  section  of  the  shipboard 

personnel.  Usage  in  turn  can  be  directly  linked  to 
simplicity  of  operation. 
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2.  Storage  Dt il ization 

Although  the  price  of  core  memory  has  been 
drastically  reduced  within  the  past  ten  years,  it  still 
represents  a  substantial  enough  investment  to  influence 
overall  system  design.  Most  common  mini-computer 
configurations  offer  32K  or  64K  of  core  memory  per 
processor.  There  exists  several  popular  schemes  available 
for  managing  the  available  memory  ranging  from  the  simplest 
of  allowing  one  user  full  access  of  core  to  sophisticated 
paging  systems.  The  best  scheme  for  utilization  of  memory  is 
basically  a  factor  of  average  program  size  and  the  number  of 
anticipated  users. 

The  shipboard  system  requires  a  time  sharing 
environment  to  support  multiple  users.  Again  space 
limitations  restrict  the  number  of  users.  In  the  case  of  a 
Destroyer  size  ship,  available  space  may  only  allow  for 
installation  of  as  little  as  four  on-line  terminals.  In  this 
situation  partitioning  memory  into  static  partitions  of  8K 
each  or  incorporating  a  simple  swapping  algorithm  should 
yield  satisfactory  results.  The  trade-off  to  be  recognized 
in  partitioning  the  memory  is  that  of  restricting  program 
size.  The  situation  that  must  he  avoided  is  one  in  which 
program  size  dictates  programmers  writing  sophisticated 
programs  at  the  expense  of  program  clarity  and  simplicity  of 
utilization . 
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3.  Operating  S ystem  Complexity 

Here  again  the  trade-off  is  one  cf  convenience  vs 
core  utilization,  host  mini-computer  manuf ac turers  offer  one 
or  mere  operating  systems  for  their  particular  machines. 
Before  deciding  on  a  system  with  more  than  one  operating 
system,  the  purchaser  should  require  a  demonstration  or  the 
degree  of  difficulty  and  time  required  to  exchange  the 
operating  system  residing  in  core  with  one  from  a  mass 
storage  device. 

The  limited  number  of  simultaneous  users  in  the 
shipboard  environment  dictates  a  rather  simple  minded 
operating  system.  Often  a  manufacturer  will  try  to  sell  the 
most  sophisticated  operating  system  developed  for  his 
machine.  It  may  prove  worth-while  to  consider  building  an 
operating  system  designed  specifically  to  match  the  desired 
requirements  cf  that  particular  installation.  The  points  to 
keep  in  mind  in  making  the  decision  are  that  too  complex  an 
operating  system  will  overburden  core  and  that  the  more 
sophisticated  the  operating  system  the  greater  the 
probability  cf  it  containing  holes  or  errors  not  previously 
encountered . 

4  .  Extent  of  Cocumentat ion 

Every  programmer  is  continually  reminded  of  the 
value  cf  program  documentation.  In  the  mini-computer 
environment,  while  the  value  of  documentation  can  net  be 
overlooked,  one  must  recognize  that  trade-offs  exist.  It  is 
a  true  consequence  that  source  program  documentation  causes 
programs  to  be  larger  and  take  up  more  space.  In  the  case  of 
the  EASIC  language,  which  is  interpretive,  the  whole  source 
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program  is  put  into  core  at  run-time,  and  source  statements 
are  interpreted  as  they  are  sequentially  executed.  Thus 
blank  cards  inserted  for  spacing  consume  space  within  core. 

If  the  source  language  of  a  program  may  be  compiled 
or  assembled  and  gotten  into  core  image  form,  internal 
documentation  will  not  affect  the  size  of  the  loaded  program 
at  run-time,  a  compromise  that  exists  is  tc  store  the  source 
program  on  magnetic  tape  and  store  the  core  images  of 
frequently  run  programs  on  disk.  Another  alternative  is  to 
have  two  versions  of  a  program;  one  fully  documented  and 
stored  cn  magnetic  tape  and  the  other  with  no  documentation 
avaiable  cn  disk. 


5.  Assembly  vs  H iqh  Level  Language 


Another  trade-off  that  must  be  considered  is  the  use 
of  assembly  language  to  save  core  and  disk  space  or  the  use 
of  a  high  level  language  for  ease  of  programming  and  program 
maintenance.  The  Data  Processing  Technicians  who  will  be 
assigned  aboard  ship  will  generally  possess  little 
background  in  working  with  assembly  language.  In  most 
instances  the  Data  Processing  Technicians  will  only  be 
familiar  with  CMS-2,  used  on  Navy  tactical  systems,  or 
COECL.  These  programs  where  maintenance  is  anticipated  or 
unigueness  is  not  desired  should  be  written  in  a  high  level 
language.  The  operating  system  and  training  programs  where 
standardization  among  ships  of  a  class  is  the  desired 
objective  should  be  coded  in  assembly  language. 


The  choice  of  the  high  level  language  to  be  utilized 
in  the  applications  programs  is  greatly  influenced  by  the 
hardware  selection  and  the  amount  of  core  purchased.  While 
it  would  be  desireable  to  write  the  programs  in  COBOL  due  to 
its  familiarity  among  Navy  DPs,  it  is  not  presently  a 
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practical  alternative.  The  cere  requirements  of  available 
CCEOL  compilers  have  resticted  implementation  of  COEOL  in 
the  mini-computer  environment.  The  development  of  a  new 
high  level  language  incurs  a  high  initial  cost.  Some 
currently  available  popular  mini-computer  languages  and 
their  descriptions  are  as  follows: 

a.  FOCAL 

FOCAL  is  a  simple  programming  language  which  was 
designed  for  implementation  on  the  DEC  PDP-8.  FOCAL  is  non 
block  structured.  Variables  are  not  declared  in  FOCAL. 
Storage  is  allocated  for  a  variable  after  the  first 
occurrence  of  a  SET  command.  Array  elements  are  allocated 
cne  at  a  time  when  they  are  first  referenced  in  the  program. 
FOCAL  supports  the  standard  arithmetic  operators,  but 
relational  operators  are  not  implemented.  Program  control 
is  provided  by  the  IF,  GO,  GOTO,  DO,  RETURN,  and  FOR 
statements.  I/C  is  not  very  sophisticated  in  FOCAL.  The  I/O 
commands  are  ASK  and  TYPE.  FOCAL  provides  quite  a  number  of 
built  in  functions  (i. e.  trigometric)  and  has  the  facility  to 
let  the  user  define  his  own  functions.  Although  FOCAL  is 
easily  learned,  it  is  machine  oriented  and  bcund  to  the  PDP. 
Its  usefulness  in  simple  program  application  is  offset  by 
its  lack  cf  power  and  transportability. 

b.  EI-11 


PL-11  is  a  block  structured  language  which  was 
created  for  use  on  the  DEC  PDP-11.  PL-11  constructs  are  good 
for  writing  readable,  structured  programs.  All  variables  and 
procedures  in  PL-11  must  be  declared.  The  Bit  data  type 
allows  the  user  to  reference  individual  bits  in  main  memory 
through  use  cf  the  SET  and  CLEAR  commands.  PL-11  offers  the 
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standard  arithmetic  and  logical  operators.  Iterative  control 
within  a  program  is  effected  through  use  of  a  standard  type 
of  looping.  Nesting  of  procedures  to  any  desired  level  is 
permitted  and  recursive  calls  are  allowed.  By  declaring  a 
variable  to  be  of  type  STACK  the  programmer  may  make  use  of 
the  POSH  and  POP  functions  which  serve  to  manipulate  the 
top-of-stack  element.  PL-11  functions  make  special  use  of 
PDP-11  hardware  features  and  is  thus  non-transportabl e . 

c.  C 

C  is  a  compiler  that  was  first  developed  on  a 
PDP-11  anc  used  to  implement  the  UNIX  operating  system.  C  is 
neither  block  structured  nor  based  on  a  commonly  used  high 
level  laguace.  C  supports  the  standard  arithmetic  and 
relational  operators  and  in  addition  some  unusual  operators 
influenced  by  the  hardware  of  the  PDP-11.  Program  control  is 
accomplished  through  use  of  the  IF,  WHILE,  FOR,  DC,  and 
SWITCH  statements.  The  SWITCH  statement  is  equivalent  to 
the  traditional  "CASE"  statement.  Functions  in  C  may  be 
recursively  called.  Formatted  I/O  is  accomplished  through 
library  routines  which  convert  decimal,  octal,  and  floating 
point  values  to  or  from  ASCII.  As  with  the  two  previously 
mentioned  languages,  C  is  highly  machine  dependent. 

d.  ECRTRAN  IV 

Many  mini-computers  make  use  of  powerful  FORTRAN 
compilers.  Using  a  standard  operating  system  implemented  in 
assembler  code,  they  provide  the  capability  for  supporting  a 
powerful  E GEIfiAN  which  is  compatible  with  IBM's  level  G 
compiler.  Utilizing  an  INLINE  statement  they  allow  inclusion 
of  assembler  code  between  FORTRAN  statements  providing 
greater  programmer  flexibility.  The  drawback  of  these 
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compilers  ,  as  with  all  FOBTBAN  compilers,  is  the  difficulty 
encountered  in  utilizing  them  in  non-numer ical  applications. 


e.  EASIC 

The  programming  simplicity  of  EASIC  has  made  it 
one  of  the  mcst  popular  mini-computer  languages.  The  editor, 
file  storage,  and  program  execution  are  combined  into  a 
single  system  allowing  BASIC  to  be  independent  of  any 
operating  system.  The  Dartmouth  standard  EASIC  includes  more 
powerful  constructs  than  it's  FOBTBAN  IV  counterpart  by 
supporting  string  manipulations,  matrix  operations, 
formatted  I/O,  external  subroutines  and  a  file  system. 
Additionally,  EASIC  programs  execute  interpretively  which 
circumvents  problems  of  compilation  caused  by  limited 
memory.  With  suitable  extensions,  BASIC  can  be  used  for  a 
variety  cf  sophisticated  and  demanding  applications.  A 
EASIC  programmer  does  not  manage  main  memory  directly. 
Instead,  he  manages  program  space  which  consists  of  numbered 
instructions  and  variables  both  of  which  require  space  in 
main  memory.  When  EASIC  programs  become  too  large  tc  fit 
main  memory,  the  programs  must  be  broken  into  overlay 
modules  with  inter-module  sequencing  logic.  Beference  9 
presents  a  structuring  and  design  strategy  for  managing 
overlays . 


Weighing  equally  the  factors  cf  programmmers 
ability,  machine  independence,  and  power  of  the  language,  an 
extended  version  of  EASIC  becomes  an  attractive  choice  of  a 
high  level  language  for  use  in  the  shipboard  management 
system . 
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IV.  INTERFACE  WITH  MAPJIS 


A  high  percentage  of  shipboard  administration  time  is 
dedicated  tc  generation,  verification,  and  correction  of 
inputs  tc  the  Navy's  Manpower  and  Personnel  Management 
Information  System  (MAP MIS)  .  Presently,  source  data  is 
entered  into  the  MAPMIS  data  base  as  a  result  of  internal 
Supers  fuicticns  as  well  as  world-wide  field  data  reporting. 
The  present  reporting  process  is  error  prone  resulting  in  a 
significant  rate  of  errors  being  introduced  into  the  data 
base.  This  situation  has  resulted  in  many  costly,  faulty 
decisions  by  the  users  of  the  data  base(i.e.  detailing  an 
individual  tc  fill  a  billet  that  was  previously  filled,  but 
net  recorded  in  the  data  base) . 

The  nature  of  errors  in  the  data  base  can  be  the  result 
of  several  circumstances.  Errors  attributed  to  lack  of 
timeliness  can  occur  if  decisions  are  made  on  a  data  base 
that  dees  not  reflect  the  most  recent  personnel 
transactions.  The  most  common  errors  are  inaccurately 
reported  information  or  the  failure  to  repert  information 
reguired  tc  update  the  data  base.  The  worst  situation 
develops  when  faulty  information  that  has  been  entered  into 
the  data  base  is  used  to  edit  inputs,  resulting  in  rejection 
of  entirely  correct  information. 

The  present  method  utilized  to  handle  errors  is  to 
research  them  at  the  point  of  detection,  usually  Supers,  and 
if  possible  correct  them  and  re-attempt  to  update  the  data 
base.  This  method  of  error  research  is  manpower- int ensive 
and  even  with  the  significant  resources  presently  available, 
resolution  is  freguently  not  attainable,  causing  an 
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accumulation  of  backlogs.  Often,  reports  must  be  returned  to 
the  ships  and  shore  stations  originating  them.  When  this 
situation  arises,  errors  associated  with  timeliness  may 
result. 

Bupers  has  undertaken  a  source  data  improvement  program 
to  identify  areas  in  which  accuracy  and  timeliness  can  be 
improved.  The  short  range  plan  utilizes  existing  structures 
for  reporting.  The  current  OCR  reporting  formats  and  the 
Diary  system  will  be  maintained.  What  will  change  is  the 
method  by  which  the  data  is  transmitted,  verified,  and 
entered  into  the  MAPMIS  data  base. 


A.  REPORTING  STRUCTURE 


Under  the  MAPMIS  system,  there  will  exist  five  basic 
nodes  or  reporting  levels  in  the  system.  They  are  in  the 
order  of  their  data  processing  capability: 

1.  Central  Processing  Node 

2.  A.  E.  S. 

3.  High  level  Terminal  (HIT) 

4.  low  level  Terminal  (LIT) 

5.  Remote  Unit 

The  central  processing  node  will  be  the  MAPMIS  itself. 
The  A.  D.  S.  activities  are  those  with  large  existing 
personnel  data  bases  such  as  the  Chief  of  Naval  Education 
and  Training  (CNET) .  Ships  reporting  their  local 
transactions  will  not  be  concerned  with  these  activities. 
The  lowest  reporting  node  will  be  a  separated  unit  incapable 
of  supporting  a  low  level  terminal.  An  example  of  such  a 
unit  might  be  a  motil  medical  team  attached  to  a  Karine 
Corps  unit.  A  ship  configured  with  a  mini-computer  would  be 
considered  a  low  level  terminal  activity  reporting  personnel 
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information  to  the  MAPMIS  through  a  high  level  terminal 
activity . 

A  high  level  terminal  activity  is  characterized  by  the 
maintenance  of  a  local  data  base  kept  in  synchronization 
with  the  Supers  data  base.  This  concept  is  dependent  upon 
the  concept  of  a  centralized  base  personnel  office.  As  an 
example,  instead  of  every  Navy  activity  in  the  geographical 
location  of  San  Diego  manning  its  own  personnel  office,  a 
central  base  personnel  office  will  maintain  a  local  data 
base  cn  the  order  of  10,000  officer  and  enlisted  personnel. 

The  HIT  will  be  supported  by  a  mini-computer  with 
sufficient  disk  capacity  to  maintain  the  local  data  base. 
The  mini-computer  will  be  capable  of  intelligent  terminal 
processing  of  a  large  variety  of  data  input  formats.  The 
high  level  terminal  activity  will  support  remote  data 
stations  via  a  hard-wired  arrangement  or  through  use  of  a 
modem  and  a  telephone  data  set.  The  HIT  processor  will 
provide  operators  at  remote  data  stations  with  error 
analysis  such  as  syntax,  formating  errors,  or  validation 
errors  against  the  local  data  base. 

The  data  in  the  data  base  will  be  a  slave  of  the  central 
data  base  of  MAPMIS  and  kept  in  synchronization  through  a 
feedback  transmission  scheme.  All  HLTs  will  be  identical  in 
operation  except  for  the  number  of  personnel  within  each 
local  data  base. 

In  general,  a  low  level  terminal  activity  (LIT)  is 
characterized  by  its  inability  to  maintain  a  local  data 
base.  Although  a  ship  configured  with  a  mini-computer  surely 
has  the  capacity  to  maintain  a  local  personnel  data  base, 
its  lack  cf  telecommunications  capability  while  underway 
prohibits  synchronization  of  its  data  base  with  that  cf  the 
MAPMIS.  Therefore  it  will  be  classified  as  a  LLT  as  will 
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ships  having  nc  local  data  processing  capability;  configured 
only  with  a  simple  low  level  terminal.  The  output  of  an  LLT 
will  be  transactions  recorded  on  bulk  media  such  as  data 
tape  cassettes  or  floppy  disks  that  will  be  forwarded  tc  an 
HIT  for  input  into  the  system.  When  underway  a  ship  would 
utilize  this  approach.  While  inport,  the  ship  would  be  tied 
to  the  HIT  via  modem  and  telephone  data  set. 


B.  DATA  IB A K EMISSION 

The  greatest  density  of  data  flow  will  occur  between  the 
HLTs  and  the  central  processing  facility.  Periodically  the 
HIls  will  transmit  all  transactions  that  have  accumulated  to 
that  time.  The  central  processing  facility  will  in  turn  pass 
a  feedback  transmission  for  the  purpose  of  validation. 

A  significant  amount  of  data  transmission  will  occur 
within  the  HIT  itself.  Personnel  clerks  at  user  activities 
will  prepare  rough  worksheets  in  OCR  or  Diary  formats.  When 
entering  the  data  in  the  HLT  data  base,  they  will  select  the 
report  type  by  depressing  a  function  key.  The  system  will  go 
into  the  correct  mode  for  receiving  the  data  for  that  report 
and  provide  cues  for  entering  it.  As  the  operator  enters 
data,  static  information  will  be  provided  tc  cross  check  the 
data.  As  an  example,  if  a  man’s  social  security  number  is 
entered,  the  system  will  feed  back  the  man's  name.  The 
operator  can  then  tell  if  he  has  entered  the  social  security 
number  ccrrectly  and  if  he  is  processing  information  on  the 
desired  individual. 

The  Iccal  processor  edits  the  incoming  data  checking  it 
for  correct  format  and  syntax.  As  an  example,  when  age  is 
called  fcr,  the  processor  may  only  allow  numbers  between  17 
and  45  to  he  entered .  When  the  report  is  completed  the 
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information  contained  in  it  is  ccmpared  to  the  local  data 
base  to  ensure  that  it  is  consistant  with  infomation 
already  contained  within  the  data  base. 

An  additional  feature  of  the  HLT  will  be  the  ability  to 
prepare  formal  documents  that  require  a  signature.  These 
documents  will  be  prepared  on  the  local  line  printer  and 
forwarded  tc  the  cognizant  command  for  signature.  Services 
such  as  preparation  of  personnel  rosters  or  personnel 
"tickler"  actions  will  also  be  available  upon  request. 

When  a  ship  gets  underway,  it  shifts  from  a  remote  HLT 
user  to  a  III.  In  this  situation  a  significantly  different 
approach  will  be  taken  to  data  entry.  The  personnel  clerk 
will  still  prepare  the  data  in  rough  OCR  or  Diary  format. 
The  processing  difference  occurs  in  the  level  of  editing. 
The  ship  will  possess  no  personnel  local  data  base  acainst 
which  tc  check  the  input  data.  Data  that  is  entered  will 
only  be  checked  for  logical  correctness  such  as  format  and 
syntax.  If  the  data  passes  the  low  level  editing,  it  will  be 
output  on  cassette.  At  first  opportunity  the  cassette  will 
be  forwarded  by  courier  or  postal  servive  to  the  specified 
HLI  for  entry  into  the  local  data  base. 

If  upon  arrival  at  a  HLT,  transactions  do  not  pass  the 
editing  requirements  cf  the  HIT,  an  attempt  will  be  made  to 
locally  correct  the  transaction.  If  the  correction  cannot  be 
effected  at  the  HLT,  a  feedback  transaction  will  be  prepared 
and  returned  to  the  LIT  to  rectify  the  error. 
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c. 


PRIVACY  CONSIDERATIONS 


The  introduction  of  several  local  data  bases  requires 
that  the  standards  of  personal  privacy  as  set  forth  in  the 
Privacy  Act  cf  1914  be  applied.  The  local  data  bases  are 
part  of  a  reporting  system  and  no  decisions  concerning 
individuals  will  be  made  based  on  the  data  contained  in 
them.  Additionally/  no  disclosures  will  be  made  from  data  in 
the  data  bases.  The  data  in  the  local  data  bases  will 
subscribe  tc  the  standards  of  "routine  use"  as  set  forth  in 
the  Privacy  Act. 
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V. 


AOTGMATED  TRAINING 


The  task  of  accomplishing  the  reguired  training 
necessary  tc  insure  a  ship's  combat  readiness  takes  a  high 
percentage  cf  the  Navy's  manpower  and  fiscal  resources.  The 
moving  cf  shipboard  personnel  tof  and  maintaining  them  at 
shore  based  schools  is  a  costly  reguirement.  This 
reguirement  exists  due  to  the  complex  technology 
incorporated  in  the  training  and  the  lack  of  sufficient 
instruct icnal  personnel  to  carry  out  the  training  at  local 
command  s . 

The  training  that  is  carried  out  at  the  shipboard  level 
is  most  often  administered  tc  groups,  of  individuals.  The 
effectiveness  of  this  training  method  depends  upon  the 
competence  and  teaching  skills  of  the  instructor  and  the 
comprehension  level  of  the  personnel  receiving  the  training. 
The  method  dees  not  allow  for  differences  in  learning 
abilities  of  those  individuals  receiving  the  training. 
Additionally,  the  effectiveness  of  the  individual 
instructors  is  difficult  to  measure. 

The  use  of  the  computer  in  administering  shipboard 
training  offers  the  following  benefits: 

1.  Complex  Training  at  Shipboard  Level 

2.  Standardization  of  Training 

2.  Individuals  Taught  at  Their  Own  Face 

4.  Reduced  Training  Costs 

5.  Instant  Indi vidual/Ccmmand  Training  Status 
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A.  DEGB  £  E  CF  AUTOMATION 


Two  methods  of  utilizing  a  computer  to  assist  in  the 
training  effort  were  investigated.  They  were: 

1.  Computer  Assisted  Instruct ion (CAI) 

2.  Computer  Integrated  Instruction (CII) 

Computer  assisted  instruction  has  become  an  increasingly 
popular  vehicle  to  train  military  personnel  at  shore  based 
activities.  CAI  instruction  is  administered  predominantly 
on-line.  Under  this  method  of  instruction  a  student  receives 
the  basic  lessen  via  a  CRT  terminal,  takes  his  examinations 
on-line,  and  receives  diagnostics  and  prescrip tives  also 
administered  via  the  CRT. 

Computer  integrated  instruction  is  a  method  in  which 
basic  instruction  is  accomplished  off-line  via  printed 
materials.  Testing,  diagnostics,  and  prescript ives  are 
received  on-line.  The  off-line  training  consists  of 
programmed  instruction (PI) ,  audiovisual  instruction  (A/V) , 
and  self  study  guides  (SSG). 

Educators  generally  favor  the  CAI  method  because  it 
holds  the  individual's  attention  while  leading  him  from 
lesson  through  examination.  The  drawbacks  of  this  methed  are 
that  programs  tend  to  be  extremely  large  due  to  the  reguired 
verbosity  cf  the  lesson.  The  limited  memory  of  a 
mini-computer  system  makes  this  an  undesirable  program 
characteristic.  CAI  requires  that  an  individual  spend  long 
periods  at  the  CRT  terminal.  This  situation  could  cause 
contention  for  terminal  time  on  ships  capable  of  maintaining 
a  limited  number  of  terminals  due  to  space  restrictions. 
The  CII  method,  however,  requires  an  extremely  simple 
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insructicn  set  for  the  user.  The  system  can  be  implemented 
with  as  little  as  three  user  commands.  These  commands  should 
allow  the  user  to  check  his  training  status,  call  a  shopping 
list  of  available  examinations,  and  select  the  desired 
examina  ticn . 


E.  SYSTEE  CEEBATICN 

The  basic  support  materials  for  the  CII  will  be  prepared 
by  the  Naval  Training  Command.  Specific  subject  areas  will 
be  broken  into  several  modules.  The  normal  sequence  of 
instruction  for  each  module  is: 

1.  Take  a  pre-test  on  the  computer 

2.  Take  the  module  lesson  off-line 

3.  Take  a  post- test  on  the  computer 

The  pre-test  is  used  to  measure  existing  knowledge  of 
the  material  presented  in  a  particular  module.  Passage  cf  a 
pre-test  demonstrates  proficiency  in  the  material  presented 
in  the  nodule  and  the  qualification  will  be  entered  on  the 
individuals  training  record.  If  the  pre-test  is  failed, 
specific  lessens  will  be  presented  on  the  CBT  and  a 
hard-copy  furnished  via  the  printer.  Upcn  completion  of  the 
prescribed  material,  a  post-test  will  be  taken  on-line.  If 
the  pest  test  is  failed  the  individual  is  directed  tc  retake 
the  prescribed  lessons  for  the  module.  Figure-1  illustrates 
the  procedural  flew  cf  the  system. 
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FIGURE  1  -  PROCEDURAL  FLOW 
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C.  PILE  EECCIBEMEN'IS 


The  computer  integrated  instruction  can  te  supported  in 
its  simplest  form  by  two  data  files:  a  student  data  base  and 
an  examination  data  hase.  The  student  data  base  will  contain 
general  information  on  the  student  for  identification  and 
will  record  bis  training  status  for  the  various  training 
subjects  he  is  undertaking.  Information  to  be  included  in 
the  student  data  base  is  module  status  pre-test  and 
post- test  results,  and  start/comple tion  dates.  Figure-2 
represents  the  flew  of  information  in  the  system.  The 
student  data  base  will  be  maintained  on  magnetic  tape  and 
leaded  tc  disk  at  the  beginning  of  a  training  period.  The 
tape  will  te  updated  at  the  end  of  the  last  training  period 
of  the  day. 

The  examination  data  base  will  consist  of  a  separate 
physical  file  for  each  pre-test  and  post-test.  A  relatively 
inexpensive  method  of  maintaining  these  files  is  on  cassette 
tapes.  The  cassette  files  will  be  loaded  to  disk  upon 
reguest  cf  the  individual  user.  These  files  will  rot  be 
modified  by  shipboard  personnel. 
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c. 


DATA  ELEMENTS 


The  training  modules  should  be  structured  to  satisfy  PQS 
requirements  for  those  particular  subject  areas  where  PQS 
has  been  i np lement ed.  The  information  in  the  student  data 
base  should  be  a  complete  record  of  the  PQS  program  and  the 
status  of  each  individual  aboard  the  ship.  The  simplest 
method  of  constructing  the  file  is  to  design  it  as  a 
variable  length  file  composed  of  logical  records,  cne  per 
person.  The  number  of  physical  records  composing  each 
logical  record  will  be  a  function  of  the  degree  of  training 
reguired  for  the  individual  associated  with  that  logical 
record.  The  student  data  base  should  contain  these  minimum 
data  elements: 

1.  Name 

2.  Social  Security  Number 

3.  Work  Center 

4.  Modules  Bequired 

5.  Modules  Completed 

6.  Modules  in  Progress 

7.  Module  Start  Dates 

8.  Module  Completion  Dates 

S.  Test  Score  Results 

Additional  data  elements  can  be  added  if  desired  by  the 
Command.  This  will  affect  the  number  of  physical  records 
reguired  and  the  tctal  length  of  each  logical  record. 
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VI.  PERSONNEL  RECORDS 


The  interlace  with  3APMIS  outlined  in  Chapter  IV  is 
totally  dependent  upon  conversion  to  the  Central-Ease 
Personnel  Office  concept.  Should  this  concept  be  rejected  or 
postponed,  ships  with  data  processing  capabilities  should 
maintain  a  local  personnel  data  base.  The  data  elements 
contained  in  the  data  base  should  match  these  required  on 
the  various  paper  inputs  now  being  submitted  as  entry  data 
to  iJAPMIS. 

Reference  4  offers  a  simple  but  effective  scheme  for 
managing  a  generalized  personnel  data  base. 


A.  SYSTEE  DESCRIPTION 

The  proposed  system  requires  a  data  base  and  a 
dictionary  that  defines  the  data  in  the  data  base.  The 
dictionary  is  a  file  containing  specific  descriptions  of  the 
data  base  elements.  The  dictionary  file  contains  the 
identification,  characteristics,  and  storage  locations  of 
each  data  element  and  is  dynamically  accessed  by  I/O 
commands.  A  dictionary  manager  program  is  required  to  allow 
the  user  to  add,  change,  and  delete  records  and  to  print  the 
contents  of  the  dictionary.  A  file  manager  program  is 
required  to  allow  the  user  to  generate  report  headers  and  to 
query  the  data  base. 

The  tasic  design  philosophy  is  structured  for  a  main 
data  base  and  data  subsets.  The  subsets  provide  multi-level 
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query  by  a  series  of  selective  reductions.  The  subsets  are 
created  from  the  main  data  base  in  response  to  a  SELECT 
command.  Each  subsequent  subset  is  formed  by  an  additional 
SELECT  commend  operating  on  the  most  recently  created 
subset . 

Subsets  are  selected  based  upon  the  parameter  input  by 
the  user,  e.g.,  age  or  name.  As  an  example  of  the  subset 
reduction  process,  assume  the  data  base  contained  only  the 
following  information: 

Name:  J.  Ercwn,  Bate:  BM1 

Name:  B.  Jones,  Bate:  BM2 

Name:  A.  Smith,  Bate:  BM 1 

Name:  E.  Smith,  Bate:  BM 2 

Using  the  SELECT  command  with  the  parameter  name  Smith 
would  cause  tfce  subset  of  the  last  two  records  to  be  formed. 
Beusing  the  SELECT  command  with  the  parameter  rate  BM2  would 
form  a  subset  of  the  last  record  only.  Figure-3  shews  the 
system  flew  for  the  query  process. 

B.  USEE  CCN HANDS 

The  extent  of  the  command  set  made  available  to  the  user 
should  again  be  primarily  influenced  by  simplicity  of  use. 
It  should  allow  the  user  as  a  minimum  to  carry  out  the 
following  functions: 

1.  Add  records  to  the  data  base 

2.  Modify  existing  records 

3.  Delete  records 

4.  Scrt  records 

5.  Format  printed  reports 

6.  Display  records  on  the  CRT 
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SEARCH 


FIGURE  3  -  SYSTEM  FLOW 


A  command  missing  from  many  systems  that  should  be 
included  is  an  ’'EXPLANATORY”  command.  This  command  should 
provide  an  inexperienced  user  a  concise,  easily  understood 
explanation  cf  each  user  command  available  on  the  system. 
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VII.  CONCLUSIONS 


An  automated  shipboard  command  management  and  readiness 
information  system  is  needed.  The  basic  subsystems  tc  be 
included  are  limited  primarily  by  computer  capacity  and  the 
extent  tc  which  they  can  time-share  the  system.  A  basic 
factor  is  commonality  of  data  base  elements  to  support 
specific  subsystems. 

The  training  and  administration  function  is  the 
fcundaticn  for  assessing  operational  readiness  status  of 
individual  crew  members,  teams,  and  the  entire  ship.  This 
subsystem  must  provide  both  training  deficiencies  and 
training  attainment  data  in  the  context  of  ship-specific 
requirements .  It  should  inccrporate  the  Personnel 
Qualification  Standards  concept  and  ether  requirements 
established  by  training  directives.  Output  should  include 
reguired  training  information  from  the  ship  to  higher  levels 
of  command.  The  subsystem  will  enable  commands  to  select 
which  crew  members  and  knowledge/skill  areas  should  be 
trained  aboard  ship  or  at  training  centers  ashore. 

In  designing  any  bar dware/sef tware  system,  there  are  a 
number  cf  crucial  guest ions  to  which  the  system  designer 
must  find  answers.  One  of  the  most  important  in  a  shipboard 
application  is  the  role  of  the  human  operator  in  the 
operation  of  the  system.  The  nan-machine  interface  must 
account  for  the  limited  computer  exposure  cf  most  shipboard 
persenne 1 . 

Cost  effectiveness  will  be  enhanced  by  maximum  use  of 
the  system  and  careful  choice  of  functions  tc  be  automated. 
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Simplicity  cf  use  will  encourage  users.  Design 
considerations  that  involve  trade-offs  between  simplicity 
and  efficiency  should  be  weighted  to  favor  simplicity. 

Future  developments  in  micro-computer  software  should  be 
carefully  examined  before  actual  implementation  of  a  system. 
As  software  becomes  available  to  simplify  routine  data 
processing  operations,  the  advantages  offered  by  the 
micro-computer  in  the  areas  cf  cost  and  size  will  strongly 
favor  its  usage. 

Hany  additional  subsystems  exist  as  candidates  for 
automation  such  as  payroll,  supply,  and  PUS  accomplishments. 
Automation  of  these  subsystems  should  only  be  attempted 
after  the  training  and  administration  subsystems  are  running 
smoothly.  Such  new  projects  must  be  carefully  examined  to 
determine  tleir  contention  fcr  system  resources. 
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